We (Christophe, Pablo and me) find that the naming #withAllForBrace: not so good.

In the future we will have to explain this selector in books and it would be nice to have an explicit name easy to explain. Maybe #fromBracedSyntax:? Since we do not create only collection (we want to be able to create points or rectangles). This seems easier to explain to students

It is ok for me.
Now withAll: is the default to fill up a dictionary so it is least surprise.
So we could have withAllForBraceSyntax: (but I'm not a big fan of Syntax).
#fromBracedSyntax: looks a bit strange to me. After we can change this

Suggestion: the ‘motivation’ section in the proposal should perhaps better clarify the need for a syntax extension. At the moment it’s not so clear, at least to me, why it would not be sufficient to implement some binary selector, say #*, on Collection’s class as an alias for #newFromArray:, allowing one to write:

Set*{1 . Set*{2 . 2} . 1}.
  "=> a Set(a Set(2) 1)"

Bag*{1 . Bag*{2 . 2} . 1}.
  "=> a Bag(1 1 a Bag(2 2))"

Dictionary*{ #a -> 33 . #b -> 44 }.
  "=> a Dictionary(#a->33 #b->44 )"

Suggestion: the ‘motivation’ section in the proposal should perhaps better clarify the need for a syntax extension. At the moment it’s not so clear, at least to me, why it would not be sufficient to implement some binary selector, say #*, on Collection’s class as an alias for #newFromArray:, allowing one to write:

Set*{1 . Set*{2 . 2} . 1}.
  "=> a Set(a Set(2) 1)"

Bag*{1 . Bag*{2 . 2} . 1}.
  "=> a Bag(1 1 a Bag(2 2))"

Dictionary*{ #a -> 33 . #b -> 44 }.
  "=> a Dictionary(#a->33 #b->44 )"

Wow, that is a great idea ! I love it. Not sure about which binary selector would be best, but that is a secondary discussion.

Suggestion: the ‘motivation’ section in the proposal should perhaps better clarify the need for a syntax extension. At the moment it’s not so clear, at least to me, why it would not be sufficient to implement some binary selector, say #*, on Collection’s class as an alias for #newFromArray:, allowing one to write:

Set*{1 . Set*{2 . 2} . 1}.
  "=> a Set(a Set(2) 1)"

Bag*{1 . Bag*{2 . 2} . 1}.
  "=> a Bag(1 1 a Bag(2 2))"

Dictionary*{ #a -> 33 . #b -> 44 }.
  "=> a Dictionary(#a->33 #b->44 )"

I like it (as Sven, I would probably not use * but another selector, but that's another discussion :) ).
@Ducasse what do you think about this?

if *{ is a message then what are . and }.
I do not see how this can work with *{ as a message.
I think that {Set is more stable. It follows the same syntax as { } and it is a super minimal extension of curly braces. It brings generality.

So to me a message does not work. In particular because we do not have macros in Pharo. because in that case *{ should not be a message but a kind of macro. and in lisp they have a way to know the end of an expression.

Well, * would be the message, { and } are a brace array, with . in between elements.

And no, it is not a macro, I think we all agree on that.

In any case, it is a thought experiment. I think we all want no more syntax than strictly necessary.

Just to avoid any confusion, here’s the implementation of #* on Collection’s class, as an alias for #newFromArray:, I had in mind (in Tonel format):

Collection class >> * anArray [

	^ self newFromArray: anArray
]

Ah ok I see.
Then indeed no need to change the parser and I would not overload * but for example use %>
We were checking with others here the characters that we can use for selector.

Set %> { 1 . 3+3 }

So can you propose a PR? and we will close my proposal.

Wasn't one reason for changing the parser to avoid intermediate collections?

I would have like but this is the way {} is implemented.
In fact the array is created anyway internally by the bytecode and the implementation of { } was basically sending a message with the internally created array. But let us see what others are saying. At least it forced us to clean some aspects of the {} implementation

So can you propose a PR? and we will close my proposal.

I created the following pull request for it: pharo-project/pharo#15316